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ABSTRACT 


The  design  and  implementation  of  an  LALR(1J  FORTRAN 
grammar  has  Oeen  described.  Desian  reau i rement s and 
recommendations  for  a lbK  byte  microcomputer  system,  which 
woula  allow  the  use  of  the  FORTRAN  programming  languaqe  as 
defined  Oy  the  arammar  implementation,  have  been  presented. 
The  proposed  system  consisted  of  tnree  subsystems:  a FORTRAN 
compiler  based  on  t*e  grammar  implementation  which  produced 
an  intermediate  language,  a 1 i n k 1 ng- I o ade r that  enaoled 
independently  comoilec  program  units  to  oe  linkeo,  an"*  an 
interpreter  that  executed  the  intermediate  language  on  tn? 
specific  target  machine. 
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INTRODUCTION 


A.  hISTURY  OF  THE  FORTRAN  LANGUAGE 

FURIRAiy  was  produced  in  the  late  1950’s  tor  use  on  Icv' 
computers.  With  the  backinci  of  IBM,  FORTRAN  became  widely 
accepted  and  was  subsequently  developed  for  many  machines 
during  the  1960's.  The  American  National  Standards 
Committee  soeci f icat ion  of  FQRIRAN  in  l^ob  TE1  has  araoually 
oecome  accepted  ano  most  present  compilers  conform  tc  this 
s t anaa  rd  . 

I 

In  1^76  the  committee  developed  a draft  proposed 
American  National  Standard  FORTRAN  IAJ  as  a renlacem, ent  for 
the  original  Standard.  The  FORTRAN  1 anauaoe  definition 
described  in  the  proposed  Standard  included  essentially  all 
features  cf  the  original  Standard  with  the  major  exception 
being  the  removal  of  the  Hollerith  data  type.  A nu^cer  ct 
additional  capabilities  including  a character  data  type  and 
file  oriented  input/outcut  were  also  added  to  the  lanauage. 


FORTRAN  has  made  a significant  contribution  to  computer 
technology.  Its  development  provided  a language  that  was 
easily  learned  by  a wide  variety  of  people  ana  that  was 
available  for  use  on  existing  hardware.  oy  proviainc  a 
packed  statement  form  which  aid  not  rely  on  the  presence  of 
planus,  hORTRAN  allowed  more  efficient  storage  of  proarams 


and  greater  ease  of  pro dramming.  with  tne  use  of  the 
equivalence  statement  » the  control  of  storage  allocation  ov 
the  programmer  was  oermitted  for  the  first  time.  19] 

Since  its  oriainal  definition,  FORTRAN  has  become  tne 
standard  scientific  computer  lanauage.  Because  of  the 
portability  of  programs  written  in  FORTRAN  it  has  also 
become  a common  intermediate  1 anguaoe  that  has  Been 
generated  ov  language  processors  and  compilers,  as  well  as 
one  of  tre  standard  languages  for  d r o a r a m portability. 

0.  The  Uiit  OF  F ij R I c A N aITh  MICROCOMPUTER  bYSTt^S 

Recent  advances  in  tne  construction  of  digital  circuits 
nave  resulted  in  the  availability  of  low-cost  cSi  computer 
components.  These  components,  which  include  central 
processing  units,  memory  systems  and  peripherals  for 
i nput /output , can  oe  comoinea  to  form  a digital  computer 
Known  as  a microcomputer.  A large  number  of  application 
areas  for  microcomputers  have  been  identified,  such  as 
intelligent  terminals,  dedicated  processors  and  m i n i c omru t e r 


control  tasks.  T11J 

In  contrast  to  the  advanced  technology  utilized  in  ; 

microcomputer  hardware,  the  software  designeo  to  support 
microcomputers  has  been  slow  in  developing.  A great  deal  of 
applications  wor<  has  been  done  directly  in  machine  language 
since  microcomputer  con f i au r a t i ons  have  often  lacked  the 
memory  and  inout/output  capacity  to  support  program 


9 


development  in  assembly  lanquage.  fhe  use  of  assembly 
language  has  oeen  supported  by  many  microcomputers  and  when 
combined  witn  a text  editor  and  debugging  aids  formed  a 
useful  package  for  the  programmer.  To  date/  very  few  hiqn- 
level  languages  nave  been  developed  for  use  on  a 
microcomputer  system.  PLM  ft>]  is  currently  the  only  hiqh- 
level  microcomputer  systems  programming  language  which  is 
widely  used . 

•v  i t h the  expanding  number  of  acpl  icat  ions  for 
microcomputers/  high-level  1 anquaaes  must  assume  an 


i rc reas i no  1 v important  role  in  the  development  of  software 
for  use  on  m i c roc  omcu  t e r systems.  An  implementation  o'  "ne 
h OR  I R AN  language  coulo  be  a valuable  addition  to  the  "Kin- 
level  1 anquaaes  that  can  be  utilised  for  microcomputer 
software  support . 

The  purpose  of  this  paper  is  to  describe  the  (lesion  and 
implementation  of  an  LAl_R(l)  FORTRAN  grammar  for  use  with  a 
self-hosted  compiler.  An  overall  system  design  to  support 
the  hQHTKAN  language  on  a microcomputer  system  is  also 
aescrioed. 

C.  MOTIVATIUN  FUR  Aim  |_AlR(1)  GRAMMAR 

Une  of  the  major  techniques  used  in  current  compiler 
construction  is  Cased  on  worx  done  by  Knuth  L8J/  who 
developed  deterministic  parsing  algorithms  for  the  l«*ft-to- 
right  translation  of  1 anguaqes  defined  by  LR(k)  grammars.  A 


1 0 


microcomputer  system.  The  LALR  Parser  program  accepts  a 


Backus  iyaur  Form  (0NF)  grammar  definition  as  inouti  ana  tne 
number  of  lookaheads  allowed,  and  aetermines  if  the  grammar 
is  amoiguous.  If  the  grammar  is  acceotaole  then  oarse 
tables  are  produced  that  can  be  usea  with  a parser,  and 
syntactic  and  semantic  analyzer  routines,  to  provide  me 
basis  for  the  systematic  construction  of  a compiler.  Tne 
parse  tables  that  are  produced  are  compatible  with  tne  P L M 
programming  1 annuage  but  can  be  modified  for  use  with  other 
1 anguayes . 

Ire  LALk  Parser  Generator  was  instrumental  in  tne 
development  of  the  large  Grammar  necessary  for  FuPIwAt‘  since 
a N F gefinitions  could  ce  tested  and  debuogeu  incrementally 
as  tne  grammar  was  developed. 


* 
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II.  GRAMMAR  SPECIFICATION  AND  DESIGN 


A.  INTRODUCTION 


This  chapter  describes  the  reau i rement s , qoals/  and  the 
design  decisions  considered  during  the  development  of  the 
LACK  C 1 J FORTRAN  grammar.  In  addition,  suoaestecl  extensions 
to  the  grammar  are  included. 


fhe  final  two  pass  version  of  the  L A L P ( 1 ) F u P I c A N 
grammar  is  containec  in  Appendices  A and  B.  The  syntax  jf 
the  FOR  I RAN  statements  that  this  orammar  defines  is  included 
in  the  197o  draft  proposed  American  National  Standard 
F OR  I KAN . The  few  deviations  from  the  proposed  Standard  are 


noted  in  the  "Statement  Restrictions"  section  in  this 
chapter . 


o . GRAMMAR  SPECIFICATION 


The  syntax  ot  individual  FOPTPAN  statements  ana  tneir 
correct  ordering  within  program  units  described  in  tne 
proposed  Standard  were  used  to  form  the  basis  of  tne  orammar 
design.  it  should  oe  noted  that  the  grammar  developed  to 
define  the  proposed  Standard  also  s vn t ac t 1 c a I 1 y defines  the 
]9bb  AivSI  Standard  FORTRAN.  Not  considered  in  tne  design  of 
the  grammar  were  I anguaae  extensions  that  have  been  maoe  to 


. 


I 


ANSI  Standard  FORTRAN  gy  1 anguaqe  processors*  unless  they 
have  been  included  in  the  proposed  Standaro. 

C.  GRAMMAR  DESIGN 

FUR1RAN  as  described  in  Refs.  2 ana  0 has  oeen 
considered  an  inherently  ampiquous  language.  In  oroer  to 
completely  define  the  syntax  of  the  1 anguaqe  an  amhioucus 
grammar  is  required.  Since  LALRfl)  grammars  must  te 
unamoiguous  by  definition,  this  incompatibility  created 
problems  during  the  development  of  the  grammar. 

in  the  oesion  of  the  orammar  two  accroaches  were  ta«en 
in  order  to  solve  these  problems.  First,  cons i oerat i on  was 
given  to  exoanainq  the  grammar  to  define  more  tnan  tne 
syntax  allowed  when  compensating  actions  could  D e performed 
in  the  semantics  of  a compiler  implementing  the  grammar. 
Second,  if  that  approach  failed  then  the  grammar  was 
restricted  to  define  only  a suoset  of  the  syntax  of  tne 
I anquage . 

1 . Design  Goals 

The  design  qoals  for  the  LALk(I)  FORTRAN  grammar 
were:  (1)  to  adhere  as  closely  as  possible  to  the  proposed 
AMS  Standard  requirements  of  the  FORTRAN  language 
definition,  ( 2 ) to  maintain  overall  simplicity  in  tne 
grammar  and  13)  to  develop  a orammar  small  enough  to  te 
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utilized  in  a self-hosted  compiler  for  a m i c rocomout  e r 


system  with  16K  bytes  of  memory. 

2 . Tokens 

The  tokens  in  the  initial  grammar  design  consisted 
of  special  characters#  reserved  words#  an  identifier#  a 
statement  laDel#  a format  inout#  and  character#  integer# 
real  and  douDle  orecision  constants.  As  the  arammar  was 
developed  it  was  necessary  to  create  statement  termination# 
array  identifier#  exronent i at i on  ooerator  and  concatenation 
ooerator  tokens  in  orcer  to  resolve  ambiguities. 

a.  Keserved  oras 

In  order  to  recognize  FOkTkAN  ney  words#  such  as 
DIMtNSIllN#  COMMON#  RtAu#  etc.#  the  use  of  reserved  woras  was 
required  in  the  language  definition.  in  the  ANSI  and 
prooosed  AMS  Standara  FORTRAN  key  woras  were  not  reserved 
ana  could  also  be  useo  as  identifiers.  however#  in  order  to 
conform  to  normal  grammar  techniques  reserved  woro  tokens 
were  created  to  oistinguish  them  from  ioentifiers.  In 
addition  to  the  FORTRAN  <ey  words  the  logical  constants 
.TRUE,.  and  .FALSE..#  the  relational  operators  . E u . # ,nE.» 

.Gt.#  .Gl.#  .LE.  ana  .LT.#  ana  the  logical  operators  .and.# 

.NOI.»  and  .OR.  were  included  as  reserved  words  for  ease  in 
later  implementation  of  the  grammar. 
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D.  Statement  Termination 

Ihe  FORTRAN  lanauage  does  not  have  a special 
"end-o f -s t a t emen t " delimiter  equivalent  to  toe  oertoa  in 
CObUL  or  the  semicolon  in  ALGOL.  Thus/  in  order  to 
terminate  each  statement  definition  in  the  grammar  an  "eno- 
of “Statement " token  was  created.  without  this  token/  the 
LALK  Parser  Generator  was  unaole  to  differentiate  between 
individual  statements  in  the  lanauaye.  The  use  of  this 
token  must  oe  implemented  in  any  compiler  that  utilizes  trie 
grammer  but  should  be  transparent  to  the  user  ot  tne 
c omo i 1 e r . 

c.  Statement  Labels 

The  special  token  "statement  label"  was  used  to 
uefine  the  statement  laoeis  oiven  to  specific  statements. 
However/  references  to  statement  labels  within  a statement 
le.a./  GO  TO  10)  were  defined  as  integer  constants. 

d.  Soecial  Characters 

Durina  the  development  of  the  grammar  toe 
initial  set  of  soecial  characters  caused  ambiguities  in  the 
definition  of  an  expression.  The  differences  in  the  use  of 
the  multiplication  operator  * an a the  exponentiation 
operator  **  could  not  be  resolved.  A similar  problem  was 
encountered  with  the  civide  operator  / and  the  concatenation 
operator  //.  It  became  necessary  to  create  additional 


lo 


tokens  for  the  exponentiation  operator  and  the  cone  a t ena t i on 
ooerat or . 

e.  Format  Input 

The  "format  input"  token  was  included  in  the 
grammar  design  to  allow  format  statements  to  be  handled  in 
the  semantics  of  a compiler  implementina  the  grammar*  rather 
than  in  the  grammar. 

f.  Read  Paren 

A major  problem  was  encountered  in  aevelooins 
the  Grammar  to  define  the  FuPIPm'j  read  statement.  r r <» 
syntax  of  the  unformatted  r “ a d statement  was  C ^control 

information  1 i s t > ),  while  the  syntax  of  the  formatted  read 

statement  was  n E A 0 <fcrmat>.  nith  both  the  format  ana  t n e 
control  information  list  allowed  to  be  an  expression,  a 
description  of  the  syntax  of  the  two  read  statements  became 
HEAD  ( <expression>  ) and  READ  <e xo res s i on> . Since  tne 
expression  syntax  included  a rule  that  stated  *excression> 
J5=  ( <expression>  ) tnerp  was  no  way  for  an  LALR(l)  Grammar 
to  unambiguously  define  Doth  tyres  of  read  statement.  To 
solve  this  problem  a "read  paren"  token  was  created  to 
define  tne  beginning  of  an  unformatted  read  statement. 
Although  it  is  syntactically  correct  to  parenthesize  the 
format  in  the  formatted  read,  in  utilizina  trie  grammar  tne 
design  imposes  tne  recuirement  that  a parenthesis  following 
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the  HEAD  automatically  indicates  an  unformatted  read 
statement . 

g.  Identifiers  and  Array  Identifiers 

Identifiers  were  initially  designed  to  be  any 
sequence  of  one  to  si*  letters  or  numbers  beginning  with  a 
letter,  which  was  not  a reserved  wora.  However,  a prop  1 em 
was  encountered  in  rii f f erent i at i no  between  function 
references  and  array  element  references.  The  syntax  of  both 
as  defined  in  tn«  orooosed  Standard  consists  of  an 
identifier  followed  by  a Da  r en  t h es  i 2 ed  list  of  egressions, 
tor  example  A(o»3,<?)  ana  VAX(6,3,2).  Thus,  in  oruer  to 
resolve  this  oroolem  an  array  identifier  token  was  created. 

0 i s t 1 nqu i s h i na  between  identifiers  ana  arrdy 
identifiers  remains  a nontrivial  problem  and  must  oe  handled 
in  the  semantics.  Oecenaina  on  the  technique  used  it  mav 
impose  the  reauirement  that  arrays  cannot  be  referenced 
prior  to  their  definition  in  a dimension  statement. 

3 . Express i ons 

The  initial  grammar  design  included  the  FORTRAN 
arithmetic*  character  ana  Joaical  expressions  as  separate 
entities.  Tnese  expressions  are  each  constructed  usina 
identical  operands  - identifiers,  array  element  references 
and  function  references.  The  specific  tyoe  of  each  operand 
(character,  intener,  etc.)  must  be  examined  in  order  to 
determine  whether  it  is  valid  for  use  in  a particular 
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expression.  The  use  of  these  identical  operands  again 
caused  the  grammar  to  be  ambiguous.  The  solution  .as  to 


i 


define  one  aenera!  exnression  for  overall  use  in  the  FURTPAN 
grammar.  The  rules  that  were  develooed  for  this  expression 
definition  enforce  operator  precedence  for  eacn  tyoe.  The 
semantics  of  a compiler  that  uses  such  a grammar  must  be 
responsible  for  determining  what  specific  type  of  expression 
is  oeing  useo<  ana  whether  the  operands  are  valid  within 
that  type  of  expression. 

Another  oroolem  encountered  in  the  expression 
definition  was  in  enforcina  parontnesi zeo  expressions  as 
required  in  some  FOriTKAu  statements.  Tne  syntax  of  an 
expression  included  the  rule  <expression>  = 

( <express i on> ) . This  resulted  in  the  reduction  of  a 
pa ren t hes i zeo  expression  to  an  exnression  prior  to  its  use 
in  a statement.  In  oraer  to  enforce  a parenthesizes 
expression  the  rule  was  modified  as  follows: 

<expression>  ::s  <oaren  exoression> 

<caren  expressioo>  ::=  ( <excression>  ) 

The  second  rule  could  then  be  used  in  any  statements  where 
parent hes i zed  expressions  were  reouireo. 

4 . Complex  Constants 

A further  examole  that  illustrates  the  problems 
encountered  in  constructing  an  LALRCll  grammar  is  the 
definition  reouireo  for  a complex  constant.  Syntactically  a 
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complex  constant  was  oefi  ned  as  ( <real  constant> 


, 


< rea  1 


constant>  ).  However,  this  definition  could  not  De  useu  in 
the  grammar.  Examination  of  the  following  qrammar  rules  is 
necessary  in  order  to  understand  the  oroblem: 

<complex  constant*  ::  = ( <real  constant*  , 

<real  constant*  } 

<return  statement*  ::=  RETURN  <expression> 

<e'xpression>  ::=  <constant> 

! <paren  expression* 

<oaren  expression*  ;:=  ( <exoression>  ) 

<constant>  ::=  <real  constant* 

oased  on  trtese  Grammar  rules  the  neomnino  of  one 
aeri vat i on  for  the  return  statement  was  RETUkN  f < r e a 1 
constant*.  Durino  the  oarsino  of  this  statement  with  a left 
parenthesis  and  real  constant  on  the  stack  the  LALk  Harser 
could  not  determine  if  the  real  constant  shoula  be  reduced 
to  a constant  for  eventual  use  in  the  return  statement,  or 
whether  to  stack  a comma  for  eventual  use  in  a complex 
constant . 


In  attempting  to  overcome  the  oroblem  several 

alternative  rules  were  examined  for  the  complex  constant 
Definition  that  produced  similar  ambiguous  results.  The 
final  unambiguous  definition  was  as  follows: 

<comolex  constant*  ::=  <complex  heao>  <expression>  } 
<complex  head*  ::=  l <exoression>  , 

These  rules  reouire  the  semantics  to  determine  it  the 


expressions  in  the  complex  constant  definition  are  in  fact 
real  constants. 

5 . Input/Output  Spec i f i cat i on 

Ihe  syntax  of  the  F U P T R A N input/outout  statements 
included  a large  number  of  input/outDut  specifications 
associated  with  each  statement#  including  unit  numbers# 
error  specifiers  and  tile  specifiers.  The  ordering  of  these 
soecifers  and  the  specific  inout/output  specifications 
allowed  witn  eacn  statement  were  initially  included  in  t n e 
grammar  oesiqn.  However,  aue  to  the  large  numuer  of  grammar 
rules  required  to  enforce  this  syntax  a general  input/outout 
specification  replacec  them  in  the  final  grammar.  This 
requires  tne  interpretation  of  specific  input/outRut 
specifiers  for  the  input/output  statements  in  the  semantics. 

e> . Statement  Restrictions 

The  grammar  for  the  individual  FORTRAN  statements 
was  originally  designed  to  strictly  enforce  tne  syntax  of 
the  statements  in  the  proposed  Standard.  uurina  the 
development  of  the  grammar  it  was  decided  in  several  cases 
to  define  only  a subset  of  the  syntax  in  the  grammar  in 
oraer  to  decrease  the  numoer  of  rules.  Roth  the  common  and 
data  statement  syntax  enforced  by  the  grammar  allow  only  one 
namelist.  optional  commas  for  the  go  to#  type  ana  ao 
statements  were  also  excluded  from  the  arammar  develooen. 


The  first  definition  was  chosen  for  use  in  the  final 


grammar  because  it  required  fewer  rules.  The  secona  set  of 
rules  may  be  desired  for  a compiler  utilizing  the  grammar  in 
order  to  determine  when  the  last  array  declaration  is  beina 
processed. 

8 . Splitting  the  Grammar 

The  original  LALflfl)  grammar  was  desiqned  to  o e f i #n  e 
the  syntax  of  all  the  statements  in  the  FORTRAN  language. 
The  initial  grammar  definition  tnat  was  developed  contained 
dDO r o x i ma t e 1 y 35b  rules.  The  taoles  generated  h y the  L*LR 
Parser  for  tnis  grammar  took  over  1 1 K cvtes  of  memory, 
i hese  tables  were  much  too  large  to  be  implemented  in  a 
selt-hosted  compiler  for  a lo*  microcomputer  system  with  a 
4K  operating  system.  Consequently  tne  grammar  was  split 
into  two  sections.  The  first  section  contained  the  rules 
for  the  data  and  environment  definition  statements  including 
program)  subroutine)  function)  block  aata>  format)  entry, 
data)  specification  and  statement  function  statements.  The 
second  section  contained  the  rules  aefining  the  format) 
entry)  data  and  executable  statements. 


Splitting  the  grammar  in  this  manner  had  two 
advantages.  Ihe  large  table  size  was  reduced  to  SPuO  bytes 
for  section  one  ana  4?00  bytes  for  section  two.  The  split 
grammar  made  it  necessary  to  solit  the  compiler  into 


separate  programs  for  each  section;  thus  different  semantic 
actions  associated  with  identical  grammar  rules  could  oe 
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varied  within  the  separate  programs.  For  example*  a 
reference  to  an  array  element  could  be  handled  in  a 
different  manner  in  each  of  the  proqrams. 

A significant  disadvantage  of  splitting  the  grammar 
was  the  difficulty  imposed  in  the  design  of  a compiler  that 
utilizes  the  grammar  to  process  more  than  one  program  unit. 

Ihe  two  grammars  were  designed  so  that  they  could 
easily  be  combined  for  use  in  a compiler  that  operated  in  an 
environment  «here  memory  size  was  not  as  restricted. 


U . U P A V ft  rc  A U U ^ t 1 A i I U fj 


1 . Overview 

Ihe  initial  grammar  design  incluoea  rules  defining 
the  re  1 at i onsn i ps  among  program  units,  enforcina  statement 
oraer  and  defining  tne  statements  alloweo  within  tne  program 
units.  Ihese  rules  were  subseguently  grcppea  primarily  to 
reduce  the  size  of  the  parse  tables.  In  an  environment 
where  the  size  of  the  compiler  is  not  critical  these  rules 
would  provide  a useful  extension  to  the  grammar. 

2 . Program  units 

Ihe  program  units  Defined  oy  the  FORTRAN  language 
are  the  main  program,  and  the  function,  subroutine  and  block 
data  subproaram.s . A FURTRAN  orogram  must  have  no  more  tKan 
one  main  nrogram  and  can  have  any  number  of  additional 
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subprograms.  Further*  these  program  units  can  be  in  anv 
order.  Ihe  LA|_R(1)  qrammar  rules  that  were  developed  to 
enforce  these  relationships  are  as  follows: 

<proqram>  ::=  <proaram  unit> 

1 <subproqram> 

! <subnrogram>  <orogram  unit> 

<proaram  uni t>  ::=  <main  proqram> 

! <program  u n i t > <SuDorogram  u n i t > 
<SUDDrogram>  <subprooram  unit> 

! <subproaram>  <sutprograrr  uni  t> 
<Suproqram  unit>  ::  = <'unct ion  suCProgram> 

1 <subroutine  3ur<orcgram> 
i <ol ock  oat  a subprogram* 

These  productions  could  oe  of  value  if  more  than  one  program 
unit  is  to  be  comoilec  at  the  same  time. 


3.  Statement  Uraerino 


Several  versions  of  an  L A L ( 1 ) grammar  were 
developed  to  enforce  statement  ordering  within  program  units 
ano  the  types  of  statements  permitted  in  each  program  unit. 
An  LALK  ( 1 ) grammar  that  met  these  reauirements  is  presented 
in  Appendix  C.  The  parse  tables  generated  for  the  orammar 
in  Aooendi x C took  approximately  2200  bytes  of  memory. 


These  rules  could  oe  included  in  a compiler  that 
implements  the  grammar  if  the  memory  space  renui  '•ea  is 


aval  I aol e.  An  alternative  would  be  to  substitute  the 


appropriate  semantic  actions  as  is  described  in  the  aesign 
of  the  compiler  presented  later  in  this  paper. 
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III.  SYSTfcM  DtSiGN 


A.  OVtRVIEU 

The  system  desian  recommenced  for  implementation  of  tne 
F OR  I RAN  I snguaqe  on  a microcomputer  consists  of  three 
subsystems:  a FORTRAN  compiler  that  generates  a relocatable 
intermediate  lanauage  module  for  eacn  prcoram  unit  fmain 
proqram>  subroutines/  functions/  or  block  data)  in  tne 
F 0 H I H A N source  file/  a loaner  tnat  links  the  modules  that 
nave  been  aenpratea  t;v  tne  compiler/  and  an  tnteroreter  trot 
executes  the  intermediate  lanauage. 

The  system  that  is  described  is  designed  to  execute  on 
the  Intel  BOKO  microcomputer  with  1 oh  bytes  of  memory  under 
the  CP  / R 131  operatinc  system.  C P/M  is  a monitor  control 
proaram  that  provices  a number  of  basic  lnput/outout 
functions/  a console  command  processor/  ana  a comprehensive 
file  management  packaae  for  use  with  a file  system.  The 
file  system  is  maintained  on  diskettes  (floppy  oisks)  which 
contain  <£56K  bytes  of  storage.  This  operatinc  system  also 
supports  a text  editor/  a dynamic  dehuoger  and  the  Intel 
80d0  assembler.  C P / M takes  4 K bytes  of  memory ; therefore 
the  system  desian  ciscussed  for  the  implementation  ot 
F0R1RAN  has  1 2K  bytes  of  memory  available.  The  use  of  CP/V' 
or  an  ecui valent  system  on  the  80*0  microcomputer  airectly 
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affected  the  design  requirements  ana  recommendations  made 
for  the  implementation  of  FORTRAN. 

B.  COMPILER 

1 . Organ i zat i on 

Splitting  the  grammar  into  two  sections*  as  noted 
previously/  had  a direct  impact  on  the  compiler  aesign.  Tne 
compiler  was  oriqinally  envisioned  as  one  program  with 
provisions  tor  multiple  oasses.  Tne  implementation  of  fn® 
solit  FURIRAN  grammar  required  a seoarate  program  for  eacn 
grammar  and  a control  program  ^ hat  p r o v i d e d 1 i n < a g e tet.een 
the  two  programs . 

To  execute  tne  compiler  the  user  of  the  system  would 
invoice  the  control  proqram,  and  oass  the  name  of  the  source 
file  to  oe  compiled  in  the  command  line  as  a parameter  to 
the  orogram.  The  control  proaram  would  then  manayp  the 
interfaces  necessary  between  the  Dass  1 ana  pass  t compiler 
proarams  required  in  the  compilation  process.  The  final 
output  would  be  a file  containing  the  intermediate  language 
generated  by  the  compiler. 

The  system  is  designed  so  that  the  control  program 
resides  in  memory  aurino  the  entire  compilation.  Ihe  symbol 
table  area  is  left  in  memory  for  use  Py  the  pass  2 program 
after  the  pass  I procram  r»as  completed  execution.  Ihe  pass 
2 program  overlays  the  Pass  1 proaram  nhe"  reaa  into  menory 
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dv  the  control  program.  The  memory  configuration  fc 
implementation  of  this  design  is  presented  in  Myure  1 

COMPILER  MEMORY  ORGANIZATION 


Control 

P rooram 

"Scratch 

P a 0 " Area 

Symbol  Table 


Pass  1 Proaram 


Pass  2 Program 


System  Information 


Mgure  1 


2 


This  section  discusses  the  functions* 


the  design 


I 

f 
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requ  i rerrent  s ana  recommendations  for  the  control  program, 
the  pass  1 and  pass  id  programs,  and  the  interfaces  reuuired 
among  them  necessary  to  implement  trie  FuWIAn  compiler  based 
on  the  LAl_K(l)  FORTRAN  orammar. 

d . Control  Program 


The  main  purpose  of 

the 

control 

program 

i s 

t 0 

control 

the  overall 

c omp i 1 a t 

i on 

process. 

In  order 

to 

accomo 1 

lsh  inis  it  must 

pe  r f o r m 

t wo 

basic  functions: 

f 1 ) 

tne 

loading  of  the  pass  1 ana  pass  ?.  procirams  arc  th® 

initialization  of  t^eir  execution,  and  ( d)  the  maintenance 
of  common  infomaiinn  such  as  compiler  togoles  ana  symbol 
taole  necessary  to  both  passes.  This  reouires  tnat  tne 
control  p r o a r a m remain  in  memory  during  the  e n t i r ® 

compi 1 at i on  . 

The  oulk  of  the  executable  code  for  the  control 
proaram  resides  in  memory  just  below  the  CP/M  operatina 
system  (see  Figure  1 I . Upon  initiation  of  the  program  by 
the  user,  execution  begins  at  100  hex  (100H>  and  an 
immediate  jump  is  performed  to  the  first  executable  byte  of 
code  located  in  the  upper  part  of  memory. 

The  first  task  the  control  program  must  perform  is 
to  decide  whether  it  is  being  invoked  from  either  the  pass  1 
or  pass  2 proqram  or  at  the  initiation  of  the  FORTRAN 
compiler.  The  appropriate  actions  can  then  be  provided 
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based  on  this  decision.  A control  flag  which  can  be  altered 
by  the  pass  1 and  pass  2 programs  can  oe  useo  to  implement 
this  reaui rement  . 

when  the  control  program  is  executeo  for  tne 
initialization  of  a compilation  it  should  perform  the 
following  functions:  (1)  initialize  its  "scratcn  pau"  area 
for  use  by  the  oass  1 and  pass  2 programs*  (2)  save  the 
file  control  block  for  the  FORTRAN  source  file  and  open  tne 
file  for  inout * (3)  maintain  the  file  control  block  for  tne 
intermediate  1 enguaae  file  ana  open  it  for  output*  (u) 
initialize  the  svmcol  taole  area*  (5)  reao  the  executable 
tCuM)  tile  for  the  oass  1 oroaram  into  memory  becinr.  ino  at 
lOGH*  and  (o)  jump  to  10  OH  to  transfer  control  to  the  pass 
1 program. 

when  the  control  procram  is  invoxeo  at  tne 
completion  of  the  pass  1 program  it  should  check  for  a fatal 
error  in  the  pass  1 phase  of  compilation  which  would 
terminate  execution.  If  none  is  found*  the  COM  file  for  tne 
pass  2 program  can  be  read  into  memory  and  control 
transferee)  to  100H  to  begin  execution  of  the  oass  2 prooram. 

when  the  control  oroqram  is  executed  via  a transfer 
from  the  oass  2 program  it  should  again  chec*  for  a fatal 
error  in  the  pass  2 phase  of  compilation  ana  terminate 
execution  if  necessary.  It  must  also  determine  if  another 
program  unit  is  to  be  comoiled.  If  an  additional  program 
unit  is  to  be  compiled  the  control  program  must  reinitialize 
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the  symbol  table  and  "scratch  pad"  a rea#  with  the  exception 
of  compiler  toggles#  and  reload  ana  transfer  control  bac*  to 
the  pass  1 program  to  continue  the  compilation  process.  if 
no  more  proaram  units  are  present  on  the  source  file#  the 
control  program  must  close  the  FORTRAN  source  file  ana  tne 
intermediate  language  file  and  return  control  to  the  UP/M 
operating  system. 

Maintenance  of  the  file  control  blocks  by  tne 
control  program  for  both  the  hORTKAi\  source  file  ano 
intermediate  language  file  is  critical  to  the  system. 
Pointers  must  oe  maintained  tor  both  files  in  order  to 
determine  the  correct  record  to  oe  orocessen  tor  inru*-  or 
outout . 


Ihe  "scratch  oad"  area  located  in  the  control 
program  is  available  for  use  by  both  the  Pass  1 ana  pass  ? 


programs.  Information  maintained  in  this  area  can  include 
compiler  toggles#  error  flags#  and  any  other  interface 
information  required  by  the  pass  1 and  pass  cf  proorams. 


i . Pass  1 Program 


The  pass  1 program  implements  the  grammar  presented 
in  Appendix  A.  This  proaram  processes  the  FuRTPAN 
statements  up  to  (out  not  including)  the  first  executable 
statement.  Routines  for  syntactic  ana  semantic  analysis# 
symbol  table  manipulation#  and  a parser  must  be  included  in 
the  program.  This  section  discusses  the  design  requirements 
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In  order  to  stoo  the  execution  of  the  pass  1 
program  the  grammar  allows  the  parser  to  proceea  until  it 
has  analyzed  an  end  statements  when  no  executable  statements 
are  found  in  the  program  units  until  it  has  analyzed  the 
reserved  word  in  the  first  executable  statements  sucn  as  DO 
or  READ*  or  until  an  assignment  statement  is  recognized.  In 
the  case  of  the  assignment  statements  where  no  reserved  word 
is  contained  in  the  statement  (e.q.s  A = 3),  it  parses  up  to 
the  eoual  sign.  Tne  information  oreviously  scanned  for  tne 
executable  statement  must  be  saved  for  use  by  the  pass  ? 
proaram  to  crovioe  initialization  of  tne  scanner  and  to 
alio*  for  any  semantic  actions  that  need  to  be  performed, 
ay  mainfainina  a stack  that  always  contains  the  last  three 
tokens  processed * this  information  can  then  oe  nrovioeu  to 
the  pass  d program  via  the  "scratch  pad"  in  the  control 
program. 

b.  Scanner 

ihe  function  of  the  scanner  is  to  provide  tne 
tokens  aefineo  in  tne  FORTRAN  qrammar  to  the  parser.  T h e s« 
tokens  include  reserved  words/  special  characters*  the 
exponentiation  and  concatenation  operators*  statement 
labels*  identifiers*  array  ioentifiers*  "format  inputs"* 
"end-o f -s t a t emen t s " * and  integer*  real*  character,  and 
double  precision  constants.  The  scanner  that  was 
implemented  in  the  pass  1 proqram  encountered  no  special 
problems  in  recognizing  these  tokens  with  the  exception  of 
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identifiers#  array  identifiers  and  the  "end-of-sfaterent" 
token . 

Identifiers  and  array  identifiers  both  have  the 
same  structure.  They  are  a sequence  of  one  to  six  letters 
or  digits  that  begin  with  a letter.  In  oruer  to 
differentiate  between  them#  it  was  necessary  to  include 
interaction  with  the  semantics  necessary  for  processing 
dimension  statements.  when  the  reserved  word  D I V- c fj S I UN  was 
encountered  a f 1 an  was  set  to  indicate  rnat  a toxen  of  this 
form  followed  Dy  a left  parenthesis  was  an  array  identifier. 
This  flag  was  c h e c < e d ov  th®  scanner  following  the  initial 
test  tor  reserved  worjs.  if  the  flay  was  net  set#  »n® 
svmbol  was  looked  un  in  the  symbol  table  to  determine  if  it 
was  an  arrav  identifier  defined  in  a previous  dimension 
statement.  if  these  tests  failed#  the  token  was  assumed  to 
be  an  identifer.  The  use  of  this  feenniaue  imposed  tne 
requirement  that  arrays  could  not  be  referenced  in  any 
FONIRAN  statement  prior  to  their  declaration  in  a dimension 
st  at  ement  . 

The  recognition  of  the  end  of  a FORTRAN 
statement  by  the  LALR(l)  grammar  implementation  required  an 
"end-o f -s t at emen t " token  transparent  to  the  user.  A 
lookahead  feature  was  used  in  the  scanner  to  nelr  determine 
whether  the  next  line  was  a continuation  of  the  previous 
statement.  Since  normal  FORThAN  card  conventions  «*®re 
maintained#  the  decision  could  be  baseo  on  a line  position 
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pointer  that  maintained  the  "card  column 


position  of  tne 


current  symool  being  considered  by  the  scanner.  *vhen  a 

carriage  return  and  linefeed  were  encountered,  the  position 

of  the  next  nonblank  character  was  determined.  If  the 

position  was  not  "card  column"  six,  an  " end-o f -s t a t e^en t " 

token  was  passed  to  the  parser.  The  line  position  cointer 

was  also  used  to  recognize  the  end  of  valid  statement  innut  i 

at  "card  column"  seventy-two. 

c.  Semantic  Analysis 

As  noted  previously,  the  grammar  for  tne  c a c s 1 
proararr  does  "o*  enforce  the  order  and  tne  types  of 
statements  allowed  in  eacn  program  unit.  Uroer  can  ce 
enforced  in  the  semantics  of  the  orogram  by  the  use  of  two 
flags:  one  flag  to  determine  the  type  of  program  unit  beinc 
processed  (main  proqram,  suoroutine*  function,  or  block 
data),  and  a second  f 1 aa  to  determine  if  a particular 
statement  is  valid  based  on  the  previous  statements  that 
have  been  processed.  Each  statement  in  the  grammar  for  this 
program  has  an  associated  reserved  word.  Whenever  a 

reserved  word  for  the  statement  currently  being  processed  is 
encountered,  the  flags  can  be  checked  to  determine  if  the 
statement  order  is  correct  and  if  that  type  of  statement  is 
valid  in  the  program  unit. 

The  use  of  the  "format  incut"  token  in  the 
grammar  reouires  the  processino  of  format  statements  in  tne 
semantics  of  the  program.  In  addition,  this  information 


3 


f 


must  be  saved  for  later  use  by  the  oass  2 program  in  the 
processing  of  the  executable  statements.  Tnis  can  oe 
accomplished  by  either  writing  the  information  required  to  a 
floppy  disk  file*  or  by  saving  the  information  in  the 
"scratch  pad"  area  of  the  control  program.  bince  the  number 
of  format  statements  may  be  large/  the  exact  implementation 
must  be  based  on  the  actual  memory  available  for  use  in  tne 
control  program. 


I he  genera  1 

expression 

de  f i n i 

t i on  i 

n the  F 0 R T R A M 

g r amma r has 

a direct 

impact 

on 

the  pass  l 

program.  Tne 

semantics  must  f}n*orca 

the  type 

o f 

e x c r 

°ss l on 

(character, 

logical/  or 

aritnmertic)  allowed 

* i t H i 

n each 

statement  of 

the  FUKlwAN 

i nput  . 

I n some 

cases  / 

such 

as  dimension 

statements/  only  inteoer  constant  expressions  are  valid. 
Integer  constant  expressions  are  a special  case  of  tne 
aritnmetic  expression  in  which  only  integer  constants  or 
variables  of  type  integer  are  allowed.  The  semantics  of  tne 
compiler  must  also  process  these  special  expressions  and 
provide  for  their  evaluation  and  use. 

d.  Code  Generation 

The  type  of  code  generation  produced  by  a 
compiler  is  nighly  dependent  on  the  system  in  which  it  is 
implemented.  The  design  decision  to  oroouce  an  intermediate 
language  instead  of  executable  machine  code  was  based  on  t.s 
major  considerations.  First,  the  production  ot  an 
intermediate  1 anauage  enhances  the  t ransoor t ao i 1 i t v n t an 

37 


1 


eventual  system  implementation 


of  FORTRAN 


Other 


I 


t o 

microcomputers  that  suoport  Pl/M.  Second*  the  existence  of 
an  interDreter  of  Basic-E  15]*  which  translates  an 
intermediate  language  output  from  the  Basic-E  compiler,  has 
already  been  successfully  implemented  in  the  computer 
laboratory  at  the  Naval  Postgraduate  School.  This 
interpreter  is  an  excellent  candidate  for  modification  for 
use  with  FUR1PAN  if  the  intermediate  language  produced  t>y 
the  FURlRAN  compiler  is  compatible  with  the  Basic-E 
intermediate  1 anquaoe. 

S . Pass  ?.  Program 

The  oass  ? program  implements  the  grammar  presented 
in  Appendix  d.  This  a r on  r am  processes  r 0 R T * A iv  exeoutarle 
statements.  Syntactic  and  semantic  analysis*  symool  table 
manipulation,  and  Darser  routines  must  again  oe  included  in 
the  proqram.  This  section  describes  the  oesian  r egu i remen t s 
imposed  by  the  FORTRAN  grammar  and  additional  design 
considerations  necessary  for  i mo  1 emen  t a t i on  of  the  orcgram. 

a.  Parser 

The  parser,  which  controls  the  execution  of  the 
pass  £ program*  can  be  identical  to  the  oarser  descriceo  in 
the  previous  section. 

txecution  of  the  Parser  is  terminated  after  the 
eng  statement  is  parsed.  At  this  point  the  program  must 
determine  if  there  are  additional  orooram  units  to  oe 
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compiled.  This  can  be  done  by  checking  to  see  if  anything 
other  than  a soft  end-of-file  (1Ah)  or  a hard  end-of-file 
occurs  after  the  carriage  return  and  linefeed  following  the 
eno  statement.  The  appropriate  flaa  shoula  then  be  ,set  in 
the  "scratch  pad"  area  of  the  control  program  ana  execution 
transferred  to  the  control  oroqram. 

0.  Scanner 


The  scanner  designed  for  use  in  the  pass  <-? 


program 

can  be  very 

s i m i 

1 a r to 

the 

scanner  in 

the 

pass  1 

p rog r am 

. The  "read  paren” 

token 

i S 

the 

only 

ci  n vj 

i t i o n e 1 

tOK^n 

that  must  be 

recooni z e a 

by 

the 

pass 

£ 

5 c a n o r 

implementation. 

The  differentiation  between  identifiers  ana 
arrav  identifiers  is  no  longer  required  in  the  semantic 
analysis.  At  this  ooint  all  arrays  have  been  oeclarec  ana 
the  array  identifiers  are  contained  in  the  symbol  table  and 
can  be  easily  recognised. 

At  the  i n i t i a 1 1 2 a t i on  of  the  scanner,  the  tokens 
previously  parsed  in  the  pass  1 proaram  for  the  first 
executable  statement  must  be  recovered  from  the  "scratch 
pad".  Code  for  providing  these  tokens  for  analysis  ano  use 
oy  the  scanner  must  be  included  in  the  program  prior  to 
obtaining  any  new  tokens  for  the  first  executable  statement. 
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Semant i c Analysis 


As  noted  previously/  tne  format  specification  in 
the  format  statement  must  oe  handled  in  the  semantics  of  tne 
proqram.  In  addition/  Provision  must  be  made  for  retrieving 
the  information  that  was  produced  for  any  format  statements 
that  were  processed  Dy  the  pass  1 proqram. 

The  orammar  for  pass  2 imposes  adoition0l 
requirements  for  expression  evaluation  not  necessary  in  tna 
pass  1 program.  For  example/  one  form  of  tne  print 
statement  wnich  is  acceptable  to  the  orammar  is  Ptil  iT 
<e*oression>.  Tne  expression  may  either  be  an  integer 
constant  designating  a statement  label/  cr  a character 
expression.  Thus/  tne  semantics  must  allow  the  statement 
laoe)  to  be  valid  as  it  is  parsed  uo  throunn  the  expression 
definition  associated  with  a print  statement.  Similar 
requirements  exist  for  the  read  statement  ana  complex 
constant  definitions. 

d.  Code  Generation 


Since  the  pass  2 program  performs  croe 
generation  for  all  FURTRAN  executable  statements/  the 
prooram  may  exceed  the  memory  si?e  available.  If  tKis 
occurs/  consideration  should  be  aiven  to  either  restrictin'! 


the  types  of  statements  allowed  for  use  in  the  FuRIRAH 
implementation  or  to  Producing  parse  actions  in  pass  ? and 


additional  program  could  then  generate  the  intermediate 
language  cased  on  the  parse  actions/  associated  information 
and  available  symbol  table  information. 

C.  LOAULK 

The  oasic  task  of  the  loader  program  is  to  process  the 
intermediate  language  modules  aenerateo  by  the  compiler  for 
the  various  program  units#  and  to  produce  a iero’acoress 
intermediate  language  module  that  can  De  executed  c y tne 
interpreter. 

The  following  tvoes  o*  information  associated  with  each 
intermediate  language  module  are  necessary  for  loaner 
implementation:  (11  the  name  of  the  current  module#  ( 2 ) a 
list  of  external  names  end  references  witn  definitions  of 
their  use#  (3)  the  aaoress  of  the  first  byte  in  tne  coae 
area  of  the  current  moaule#  ana  (4)  the  length  of  the  coae 
area  of  the  module  in  oytes.  Output  from  the  loader  should 
be  designed  to  enable  further  linkage  if  all  external 
references  nave  not  yet  teen  resolved. 

The  actual  implementation  of  a loader  was  not  considered 
part  of  this  thesis  oroject  ana  is  left  for  future 
cons i derat  ion. 
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D.  iNTtRRRETER 


I 


I 

i' 


The  function  of  the  interpreter  is  to  execute  the  zero* 
address  intermediate  language  produced  by  either  the 
compiler  or  the  loader.  At  this  point  all  external 
references  must  be  resolved  in  order  for  the  intermediate 
language  module  to  be  interpreted. 

I he  desian  of  an  interpreter  is  dependent  cn  the 
specific  machine  on  w n i c h the  FORTRAN  lanyuaoe  is  to  be 
implemented.  The  run-time  monitor  used  for  executing  *ne 
intermediate  I annuaoe  produced  by  the  casic-t  compiler  lol 
is  an  example  of  an  interpreter  that  has  been  successful  I v 
implemented  on  tne  60n0  under  the  lP/v  operating  system. 
The  monitor  provides  a number  of  features  that  would  ce 
useful  in  the  interpretation  of  FORTRAN  such  as  the  use  of  a 
floatina  point  package  [71  to  perform  arithmetic/  function 
evaluation  and  conversion  operations  on  Id  bit  floatina 
point  numbers.  if  the  intermeaiate  1 anguaae  generated  by 
the  FORTRAN  comniler  is  designed  to  be  compatible  with  the 
language  produced  ov  the  Rasic-F  compiler/  the  modification 
of  this  interpreter  to  acceot  FORTRAN  would  areatlv 
facilitate  the  implementation  of  FORTRAN  on  the  bObO. 


L. _ 


j 


| IV.  CONCLUSIONS 

fc' 

If 

The  successful  completion  of  the  formal  FORTkAu  qrammar 
demonstrates  the  feasibility  of  defining  an  ambiouous 

f IB 

language/  such  as  FORTRAN , usinq  an  L A L R ( 1 ) grammar. 
Amoiguities  in  the  grammar  can  oe  resol vea  bv  provioino  a 
oroacjer  definition  for  the  language  and  comoensatinq 
semantic  actions  by  a comciler  that  implements  the  qrammar. 

The  FURTRAN  grammar  which  was  developeu  was  structured 
to  define  the  largest  possible  svnta*  of  the  l°)n  graft 
proposed  American  National  Standard  FORTRAN.  However,  this 
should  not  orevent  a user  of  this  grammar  from  redefining  it 
to  meet  the  requirements  for  implementation  on  a particular 
machine. 


The  use 

of 

a 

formal 

1 anouage 

ana 

automatic  parser 

generat i on 

me  t hoas 

proved  extremely 

val uaol e in 

t n e 

construction 

o f 

the 

FORTRAN 

comp i 1 e r . 

The 

parser  that 

W cj  S 

avai 1 ab 1 e for 

use 

i n process i ng 

the 

parse  taoles, 

when 

comb i ned  with 

syntactic  and 

semant i c 

anal yzer  rout i nes, 

1 ed 

to  a modular  assign  and  the  systematic  construction  of  a 
comoiler  rather  than  an  ad  hoc  technique. 

The  system  design  which  was  oresented  to  support  the 
FORIkAN  language  on  a microcomputer  system  with  lbt\  bytes  of 
memory  is  feasible.  io«i#v»r,  the  lac<  of  memory  space 


<4  3 


1 1 


remains  o problem.  It  is  recommended  that  consideration  oe 
given  to  the  replacement  of  those  rules*  especially 
input/output  statements*  which  could  be  tailored  to  tne 
specific  machine  on  which  the  compiler  is  implemented. 

It  is  hoped  that  the  LALR(l)  FORTRAN  grammar  ana  tne 
accompanying  system  cesiqn  recommenoat i ons  will  establish  a 
basis  for  the  implementation  of  FORTRAN  on  a microcomputer 
system. 


APPENDIX  A - FORTRAN  GRAMMAR  SECTION  OnE 


<proqram>  ::  = <orog  stmt>  ^program  body>  <end  state> 


<prpg  stmt>  <end  state> 


<nrograiT'  body>  <end  state> 


<end  state> 


<subr  stmt>  <orcQrai"  body>  <eny  state> 


<subr  stmt>  <enri  state> 


<func  <oroqrai"  noa/>  <enu  stafe> 


<f unc  3t^t>  <enn  state> 


<b 1 oc  k oafa  st  r.t  > <progra»r  booy  > <er>u  s t a ? e> 


<proyram  body>  ::=  < s t a t e^en t > 


! <orograin  booy>  <s  t a t amen  t > 


<st  atement  > 


<label>  <oarm  stmt>  <»os> 


<label>  <imol  stmt>  <aos> 


<1abel>  <dimen  st"nt>  <eos> 


<1abeT>  <co*«ion  <eos> 


<1abel>  <«quiv  st»t>  <eos> 


! <label>  <tvoa  st»t>  <eos> 

! <laoel>  <e*ternal  st^t*  <eos> 


<tabel>  <Tntrinstc  st"t>  <ens> 


<lab«1>  <save  stmt>  <»os> 


<1abel>  <iat  a st**>  <»os> 


<labe'>  <st,*t^ijpc  stmt>  <»os> 


! <label>  <ent  rv  stmt>  <eos> 

J <stmt  laoel>  <format  stmt>  <eos> 
<end  state>  <label>  <exec  stmt  reserved  word> 

! <label>  <i dent i f i er>  = 

J <1abel>  <srray  element>  = 

! <labe1>  <subst  ring  name>  = 

! <end  s t m t > 

<exec  stmt  reserved  word>  ::=  DO 


<block  data  stmt> 


<label>  BLOCK  DATA  <eos> 


! <)aoel>  BLOCK  DATA  <i dent i f i er>  <eos> 


<subr  stwt>  : 


< f unc  s t mt  > : 


: <1abel>  SUBROUTINE  <identifier>  <eos> 
<laoel>  SUBROUTINE  <arq  list>  <eos> 


= <label>  <*unc  id> 


<labe1>  <number  tyce>  <func  ia> 
<laoel>  <char  tyoe>  <func  io> 


<func  td>  = FUNCTION  < i den t i f i e r > <eos> 

! FUNCTION  <iaentifier>  ( ) <eos> 


! FUNCTION  <arq  list>  <eos> 


< o am  s t n t > 


< i mo  1 s t Tit  > 


< i mo  I M 5 t > 


= PARAMETER  <iaent i f i er>  = <constant> 


<oar™  s t ti  t > t <identifier> 


= IMPLICIT  < i to  1 1 ist> 


<impl  stTt>  » < i t p | Hst> 

= < i m o I list  R e a a > < I et  ter  r a n y e > ) 


< i mD I list  head>  : 


= <number  tyoe>  ( 


CHARACTER  ( 


CHARACTER  * <inteaer  constant>  ( 


<imol  list  head>  <letter  range> 


<1etter  range>  = < i dent i f i er> 

J <identi*ier>  “ <identifier> 

<dimen  stmt>  !SS  DIMENSION  <array  dec  I > 

| <dirren  stmt>  , <array  dec  I > 

<common  stmt>  = COMMON  <comTon  na|t'e>  <co.Tmon  nlist  it*»w> 
! <comTorr  stnt>  » ^common  nlist  it»m> 


<common  name>  = <emoty> 


! <label  common  name> 
! <doub  1 e s I asH> 


<common  nlist  item>  <iaentifier> 

' <array  id> 

! <ar ray  aec 1 > 

<label  common  name>  ::  = / <identifier>  / 

<equiv  stmt>  EQUIVALENCE  <eaui v nlist> 

! <equi v s t m t > , <eouiv  nlist> 

<equiv  nl i st>  <equiv  nlist  heaa>  <enuiv  nlist  item>  j 

<equiv  nlist  head>  ::=  ( <eauiv  nlist  i tem>  » 

i <#»au  lv  niist  *ieao> 

<equ i v nlist  1 t em>  , 


<equ iv  nlist  i t em> 


= <identitier> 


<arrav  id> 


<array  el emen t > 


<subst  rino  name> 


<tyoe  stmt > ::=  <nu»oer  tyoe  stmt> 

! <c  h a r tyoe  stmt> 

<number  tyDe  stmt>  <number  tyce>  <tvpe  item> 

i <numoer  type  stmt>  t <tvpe  item> 


<t  ype  i t em>  : 


= < i dent i f i e r> 


<ar ray  i d> 
<ar ray  dec  1 > 


<char  type  stmt>  = <char  tyne>  <char  name> 

i <char  tyoe  stmt>  » <cbar  name> 


<char  name> 


< i den  t i f i e r > 


< i dent  i 

f i e r > 

* <char 

1 en> 

<array 

dec  1 > 

<ar ray 

dec  1 > 

* <char 

1 en> 

<ar  ray 

i d> 

<arra y 

i d>  * 

<char  1 en> 

<external  stmt>  : : = EXTERNAL  <identifier> 

! <extemal  stmt>  t <identifier> 
intrinsic  stmt>  ::=  INTRINSIC  <identifier> 

! intrinsic  S t m t > , <1  den  t i f i er> 


<save 

3 t m t > 

: :=  SAyR 

I < s a '/  e 

li  s t > 

< s a ve 

1 i s t > 

: : = SAvE 

<save  i t e m > 

! <save 

1 i rs  t > i < save  i t e m > 

<s  ave 

i tem> 

: : = < i aent i f i er> 

! <ar ray 

i d> 

! < 1 aoe l 

common  name> 

<dat  a 

stmt  > 

::=  <da  t a 

list>  <data  clist  item>  / 

<dat  a 

1 i st  > 

<dat  a 

head>  <data  nlist  item>  / 

! <data 

list>  <data  clist  item>  , 

<dat  a 

head> 

: :=  data 

I <data  Heaa>  <data  nlist  item>  , 
<data  nlist  1 1.  em>  : : = <identifier> 

! <ar ray  i d> 

! <array  el emen  t > 

! <suostrinq  name> 

! < i >110  lied  do  list> 

UR 





<data  c 1 i st  i tew* 


< i dent i f i e r * 


< i mo  1 i ed  do  list* 


<stmt  f unc  stmt*  ; 


<entry  stmt*  ::= 


! <constant> 

! < integer  constant*  * <Constant> 

! <integer  constant*  * <ioentifier> 
! <identifier*  * <constant> 

! identifier*  * <iaent i f ier* 

::=  ( <array  element*  » <do  list*  ) 

! ( <impl  iea  ao  list*  *.  <do  1 i s t > ) 

:=  <ara  list*  = <exo* 

! <i cent i tier*  ( ) = <exo> 

E'iTKV  identifier* 


! t N 1 i'  <aro  list> 

J tMli  <i cent i f ier*  ( ) 

<format  stmt*  = FOdN'AT  <foprat  innut* 

<do  l i s t > = <i cent  1 tier*  - <e»p*  t <exc > 

! identifier*  a <exo>  , <exr>  , <exp> 
<func  ref>  ::  = identifier*  ( ) 

! <arq  list* 

<arq  Mst>  = <arg  head*  J 

<arq  heao*  = identifier*  ( <arq  element* 

I <arq  head*  , <arg  element* 

<arq  element*  <exc> 


I <array  i d> 

I * 

<arr ay  dec  1 > il-  <array  id>  <dimen  dec)  list*  <cimen  decl  ) 
<dimen  decl  list*  l 


! <dimen  decl  list*  <dimen  aec 1 * * 
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<dimen  dec  1 > ::s  <exp> 

i <e*o>  : <exo> 


<substrinq  name> 


<sut s t r i nq  dec  1 > 


<array  element>  = <array  element  list>  <e*P>  ) 

<aray  element  list>  ::=  <array  io>  ( 

! <array  element  list>  <exc>  > 

- <ident»fier>  ( <substrinq  dec  I > 
<array  element>  l <substrina  dec  I > 

= <exp>  : <exp>  ) 

<e xo>  : ) 

: <exD>  ) 

: ) 

<exr>  : : = < 1 c a 1 c a 1 t e r m > 

5 <exp>  . u P . < 1 o a i c a 1 t e r m > 

<loaiCdl  term>  <togical  factor> 

J <locical  term>  . AUb . < 1 og i c a I tactor> 


<loqical  f 3Ctor>  : 


= <logical  prjnary> 

.NOT.  <1oaica1  nrimarv> 

: = <cnar  exp> 

! <char  exo>  <rel  op>  <cHar  exc> 
<char  exp>  ::=  <aritn  exp> 


< I oq i c a I or i ma  ry > 


! <char  exp>  <aouble  slash>  <arith  exp> 

v 


<arith  exo>  <arith  term> 

+ <aritn  term> 

- <arith  term> 

<antf i exp>  t <aritn  term> 
<arith  exp>  - <aritH  term> 
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<arith  ten *>  = <anth  factor> 

} < a r i t h t e r m > / <arith  f actor> 
i <aritH  tern>  * <aritn  factor> 

<arith  factor>  ::=  <arith  primar>> 

| <arit^  f actor>  <expon  op>  <arith  orimary> 
<an  th  orimary>  <constant> 

! < i Pent i f i e r> 

! <array  e) effent> 

! <sut>strinq  namp> 

! < tunc  re  f > 

! <par«n  e<o> 


<caren  e x c > 
<const ant > : 


: = l <»*r>  ) 

- <intager  constant  > 

< rea 1 cons  t ant  > 

<dp1e  ore  constant> 

< 1 ooi ca 1 const  ant  > 

<cnar  constant> 

<COT'plex  constant> 

<complex  constant>  = C <real  consrant>  > <real  constant)  ) 


<rel  op> 


= .LT. 
.Lt. 
.EU. 
.NE. 
.Gf. 

• Gt  • 


<looicai  constant)  ::=  .I<?UE. 


FALSE 


1 


<numoer  tvpe>  ::=  INTEGER 
! REAL 

! DOUBLE  PRECISION 
: COMPLEX 
! LOGICAL 

<c  h a r t ype>  ::=  CHARACTER 

! character  * <char  1 en> 

<char  I en>  <paren  exp> 

J <inteqer  constant) 
It*) 

<1 abel > <emotv> 

! <stmf  1 a b e 1 > 


APPENDIX  8 


FORTRAN  GRAMMAR  StCTIUN  T/,0 


<program>  ::=  <orograrr  body>  <end  stmt> 
<DPogram  body>  ::  = <s t a t emeo t > 

i <orogrann  body>  < s t a t e^en t > 
<statement>  ::=  < 1 a b e 1 > < d a t a stmt>  <eos> 


<label>  < 1 o g i f ’ s t m t > 


<laoel>  <ao  «5 1 ^ C > <eoi> 


< I a D e 1 > <entry  s t nn  t > <eos> 


< 3 *■  n t t anel  > <fomat  s t m t > 


< 1 og  i f exec  s t r>  t > 


<logif  exec  stfnt>  <label>  <assign  stnt>  <eos> 


<laoel>  <goto  s t rr  t > <eos> 


<lanel>  <aritnif  stmt>  <eos> 


< 1 abe 1 > <continue  stmt>  <ecs> 


<lacel>  < s t od  s t on  t > <eos> 


<labei>  <pause  stmt>  <eos> 


<lape1>  <call  stwt>  <eos> 


<label>  <return  st"t>  <eos> 


< I a D e 1 > < r e a d write  print  s t n t > <eos> 
<iacel>  <open  close  inquire  strt>  <eos> 

< 1 aoe  I > <nac*<soace  enable  rewind  str>t> 


<eos> 


<end  strt>  : : = END 


<data  stmt>  <data  list>  <data  cHst  item>  / 
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<data  1 i s t > ::=  <data  nead>  <data  nlist  item*  / 
i <data  list*  <data  clist  item*  , 

<data  head*  = DATA 

! <data  head*  <data  nlist  item*  , 

<data  nlist  item*  <identifier> 

! <array  id> 

! <a p ray  el e*en t > 

! <suDst  r i ng  name* 

! < i mp 1 i ea  co  list* 

<data  clist  i te«t>  ::  = identifier* 

1 <Const  ant  > 

! < i n t e g e r constant*  * <ccnstant* 

! <intejer  constant-*  * identifier* 
1 identifier*  * <constant> 

! < l dent i f i er>  * < i aen t i f i e r > 

implied  do  list*  ( <array  element*  t <do  list*  ) 

! ( implied  do  list*  » <ao  list*  ) 

<pause  stmt*  PAUSE 

1 PAuSt  inteoer  constant* 

I PAUSt  < c r.  a r constant* 

<stop  stmt*  ::=  STOP 

! STOP  inteaer  constant* 

! STOP  <char  constant* 

<continue  stmt*  ::  = CONTINUE 
<return  stmt*  RETURN 

! RtTURU  <exo> 

<aritt>if  stmt*  ::  = It  <paren  e*o>  <aif  slaoels* 


< a i t si abe 1 s> 


<inteqer  constant> 


<integer  constant)  , 


<i nteaer  constant) 

<loaif  stmt)  ::  = IF  <caren  e*o>  <loqif  exec  stmt> 

<assign  stmt>  = ASSIGN  <integer  constant)  ID  identifier) 
! <identifier>  = <exo> 

! <array  element)  = <exp> 

! <substring  name)  = <exD> 

< d o stmt>  DO  <integer  constant)  <do  list> 

<aoto  stmt>  ::  = uO  TO  <i nteoer  constant) 

J GO  10  < s t m t label  list)  ) <e«a> 

! GO  10  identifier) 

! Gu  TO  < i dent i t i er>  < s t n t I aoel  1 i s t > j 
<stmt  laoel  1 i s r > ( <inteoer  constant) 

! <stmt  label  list)  > <mteger  constant) 
<call  stmt)  : : = CALL  < i dent i f i en> 

! CALL  <aro  list) 

<entry  stmt)  ::=  ENTRY  identifier) 

{ ENTRf  <arq  list) 

J tNTRy  < identifier)  ( ) 

<format  stmt)  = FORMAT  <f ormat  inout> 

<open  close  inquire  stmt>  ::  = <open  close  inquire  head) 

<exo)  ) 

! <ooen  close  inquire  teaa> 

<io  spec)  ) 

<ooen  close  inquire  nead)  ::=  OPEN  C 

! ClOSF  C 
! INQUIRE  C 


5b 


! <open  close  inauire  heai)> 


<exr>> 


5 <ooen  close  inauire  head> 


<io  SDec> 


<backspace  endfile  rewind  stmt>  bACKSPACt  <ber  list> 

! E N D K I L E <ber  I i s t > 


! REWIND  <ber  list> 


<ber  1 i s t > = <exp> 


! ( < e x n > » <io  soec>  ) 
1 l <io  scec>  t <exo>  ) 


<read  write  print  stnt>  ::=  <read  print  stmt> 

! < r ead  «ri  t<>  ci  I i s t > 

! <read  writ0  i o list> 


<reaa  print  stmt> 


= kE  AD  < e x p > 


READ  <arrav  i a > 


REAP  * 


PrINT  <exp> 


PRINT  <array  id> 


PRIhT  * 


<read  print  st'T't>  » <io  list  ifew> 


<read  write  io  1ist>  <read  write  ci  list>  <io  list  item> 

i <read  write  io  list>  » 

< i o list  i t em> 

<read  write  ci  1 i s t > = <read  write  Reaa>  <ci  list  ite*p>  ) 


<reaa  write  nead>  : 


= <read  paren> 


WRITE  ( 


<read  write  heau>  <c i list  iten>  , 
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■ 


<c  i list  item>  ::=  <exp> 

<io  soec> 


< a r r a y i d > 


<array  block  item>  ::  = <ar ray  element>  : <array  element) 

! <arrav  element>  : 

J : <a r p ay  el emen t > 

<io  implied  do  1ist>  ;:=  <complex  heart)  <do  list>  J 

! <io  do  list  nead>  <do  Hst>  ) 

<io  do  list  nead>  <complex  head>  <exc>  , 

( < a r ray  i d>  » 

( <array  oloc*  i , 

C <io  imolied  do  list>  > 

<io  do  list  head>  <io  list  item>  , 
<io  list  item>  ::=  <exo> 

i < a r r av  i d> 


! blank  - <e*o> 

! ACCtSo  = <e*o> 

! RORM  s <exr>> 

! RECL  = <e*P> 

! ^ A X R E C = <exo> 

! ExI5T  = <exp> 

S OPENED  = <exp> 

{ NUMoER  - <exc» 

; na^ED  - <exp> 

! M A M t = < e x o > 

! NEX  TR£C  = <e*c> 

< do  I i s t > ::=  <i'3entifier>  = <exp>  # <e»c> 


< func  r e f > 


<arq  li st> 
<arq  head> 


<arq  element 


<iTert i tier>  = <?xn>  , <exn>  , <exo> 

- < i den  t i f i e r>  ( j 


<a  rq  1 i s t > 


= <arg  nead>  ; 

= <identifier>  ( <ara  element> 
<ara  head>  > <ar g element> 


::=  <exc> 


<ar  ray  i rl> 

* <integer  constant> 


<arrav  element>  ::s  <array  element  list>  <exp>  ) 

<aray  element  I ist>  <arrav  ia>  ( 

1 <array  element  1 i s t > <exr>  , 
<substrinq  n ame>  !:=  <identifier>  l <substrinq  dec  1 > 

! <array  elempnt>  ( <substring  dec  1 > 


1 


<substrina  dec  1 > t 


= <exp>  : <exp>  ) 


<exp>  : ) 


: <exo>  ) 


<exp>  = <logical  term> 


i <exp>  .OR.  <loaical  ten'> 
<loaical  term>  = <logical  f actor> 


! <1ogica1  term>  .AMO.  <logical  factor> 


< 1 oqi ca I factor>  : 


<loqical  orimarv> 


logical  orii>ary> 


.tUT.  <looical  orimarv> 


: 2 <coar  exp> 


! <cnar  ?xo>  <rel  op>  <char  »xr>> 


<cnar  exo>  ::=  <art  tn  exp> 


! <cr>ar  exp>  <douhle  s 1 a s h > <ari  tn  e x o > 


<ari tn  exc>  <arith  t e p m > 


♦ <arith  tern> 


- <arith  tern> 


<ari tn  exp>  ♦ <arith  tern> 


<anth  e x p > - <arith  term> 


<arith  term>  = <arith  f actor> 


j <arith  term>  / <aritn  factor> 
! < a r i t h term>  * < a p i t h tactor> 


<apith  factoP>  <apitm  ppimapy> 


i <apitH  fact0P>  <expon  oo>  <apitH  priinapv> 


<apith  ppimary>  = <constant> 


J < i cent i f i ep> 


! <appay  el ement > 
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<paren  exp> 
<constant> 


J <substring  name> 

! <func  ref> 

5 <paren  exp> 

:=  ( <exr>  ) 

■ <inteqer  constant> 

<real  const  an t > 

<dp]e  pre  constant> 

< 1 oq i c a 1 constant> 

<char  constant* 

<COnrplex  constant* 

<conp1ex  constant*  ::  = <comnl«»x  neail*  J 

<coninlex  heaa*  = ( <exo>  , 

< re  I op*  : : = . L T . 

.Lt. 

. E u . 

.ME. 

.GT  . 

.GE. 

<1ogica1  constant*  .TRUE. 


.FALPE. 


<1abe1>  : : = <empty> 

I <stmt  1 abel > 
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APPEND  I X C - FORTRAN  GRAMMAR  FOR  STATEMENT  ORDtE 


<orogram>  <orogram  unit* 

5 <suborograit> 

! <suborogram>  <proyram  unit* 

<orograT  unit>  = <matn  orogram> 

! <rrcgram  uni  t>  <suoorogran  uni  t> 
<suboroaram*  ::=  <subcroyram  unit> 

! <subproqram*  <suoorogram  uni t> 

<sunoroaraT  uni t>  : : = <funct ion  suooroqpan> 

! <sui)  routine  suhproaram* 

! <d1oc'<  aata  subprogram* 

<main  orograni>  ::  = <proa  stnnt>  <main  Droqrair  body* 

i <main  program  bodv> 

<subrout ine  subprograrr>  = <subr  stmt>  <sub  program  body* 

! < sub  r stmt*  <rr.ain  program  bortv> 

! <suor  s t m t > <bloc*  aata  boay> 

! < sue r stmt>  <end  Stmt> 

<function  subProgram>  ::=  <func  stmt>  <sub  program  body* 

! <func  stmt>  <main  program  body> 

! <func  s t m t > <o1ock  aata  body* 

! < f unc  S t m t > <enq  Stmt> 

<bloci<  data  suborogram>  :;s  <hlock  data  stmt> 

<block  data  oooy> 

! <b1oc*  data  stmt>  <era  stmr> 


<main  program  oody> 


<main^  e*ec>  <end  stmt> 


<subprogram 


<b I oc  k data 


<b I o k 1 i mo  1 > 


<bloK?  soec> 


<blok3  data> 


<ma i n 1 i mp ) > 


body > : J = <mainl  i mo  I > <end  stmt> 
! <main2  sDec>  <er»d  stmt> 

! <maini  func>  <end  stmt> 

! <subl  imol>  <eno  stmt> 

! <suo?  spec>  <end  stmt> 

! <sub3  f unc > <eno  stmt> 

! <sub<J  exec>  <ena  stmt> 

! <Suo5  return)  <end  stmr> 
t;oav>  = <blokl  i -no  1 > <ena  stmt> 
! <blok?  soec>  <end  stmt> 

! <o  1 o k j aata>  < e n d s t m t > 


• • 
• • 

- < \ mp 1 

Stmt  > 

1 

1 

<oa  rm 

stmt> 

1 

1 

<b 1 ok  1 

i mo  1 > 

< 1 mp  1 

Stmt  > 

1 

• 

<b ) ok  1 

i mo  1 > 

<pa  rm 

s t m t > 

• • 
• • 

= <scec 

S t mt  > 

1 

• 

<b 1 OK  1 

» mo  1 > 

<soec 

S t mt  > 

1 

• 

<b 1 ok? 

sp*c> 

<SDec 

S t m t > 

1 

• 

<b 1 on? 

sprc> 

<parm 

S t mt  > 

• • 
• • 

= <data 

Stmt> 

» 

« 

<b 1 OK  1 

i mp  1 > 

<dat  a 

stmt> 

1 

• 

<b 1 ok? 

spec> 

<dat  a 

Stmt  > 

• 

« 

<b l ok  3 

dat  a> 

<dat  a 

S t m t > 

< f o rm  at  stmt> 

J <blokl  i mp  I > <format  stmt> 
J <mainl  i mo  1 > <imp1  stmt> 


3 


<mainl  imol>  <Darm  stmt> 


: £ 


<main2  spec> 


<TainJ  tunc  > 


<mainU  exec> 


I <mainl  imp1>  <format  stmt> 

::=  <otner  soec  stmt> 

1 <blokl  imol>  <other  soec  stmt> 
! <blo*2  spec>  <other  soec  stmt> 
! <blofc2  spec>  <format  stmt> 

J <mainl  imol>  <other  soec  stmt> 
J <mainl  imp1>  <scec  stmt> 

! <«a  i n2*  soec  > <other  spec  stmt> 
! <main2  spec>  <spec  stmt> 

{ < m a i n P soec>  <car»  st?t> 

| < « a i n ? sp“c>  <tor»at  stTt> 

;;r  <sttf  func  stmt> 

1 <blo«l  i me  I > <stmtfunc  S t nr  t > 

! <blo<?  sof>c>  <stmtfunc  stwt> 
i <b)ox3  bata>  <stmtfunc  st™t> 

! <blok3  data>  <format  stmt> 

! <mainl  i mp  1 > <stmtfunc  s t m t > 

| <mainl  i mp I > <data  stmt> 

! <main2  spec>  <stmt  func  stmt> 

I <main2  soec>  <aata  stmt> 

J <inainj  func>  <strotfunc  stmt> 

} <main3  func>  <aata  stmt> 

J <main3  f unc>  <format  stmt> 

::=  <exec  stmt> 

S <blokl  imp|>  <exec  stmt> 

J <blo«2  spec>  <exec  stmt> 
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<sub  t i mp  I > 


<sub<?  soec> 


<b l ok  3 

dat  a> 

<exec 

S t m t > 

<ma i n 1 

i mp  1 > 

<exec 

stmt> 

<ma i n2 

spec> 

<e»ec 

S t mt  > 

<ma i n 3 

f unc> 

<exec 

Stmt  > 

<ma i n4 

exec> 

<exec 

Stmt> 

< m a i n 4 

e<ec> 

<aa  t a 

S t m t > 

<ma  i r»4 

exec> 

< format  stm 

<entrv 

s t mt  > 

<0 1 OK  1 

i mp  1 > 

<entrv  s t m t > 

<ma i n 1 

i mp  1 > 

<ent  ry  stmt  > 

<SuO  1 

imcl> 

< i mo  1 s t m t > 

< suo  1 

i mp  ) > 

< p a r ' r-  st"t> 

<suo  I 

i mo  1 > 

< format  s t m t > 

< 3uD  1 

i mr  1 > 

<ent  ry  s t mt  > 

<sa  ve 

St  mt  > 

<0 1 ok  1 

i mo  1 > 

<save  stmt> 

<o  1 ok<f 

spec> 

<save  stmt> 

<b  1 ok2 

soec> 

<ent  rv  s t mt  > 

<ma i n 1 

i mp  1 > 

<save  s t m t > 

<ma  \ r\d 

so  ee> 

<save  stmt  > 

<ma  i nd 

soec> 

<ent  rv  stmt> 

<SUD  1 

i mp ) > 

<other  soec  stmt> 

<sub  1 

i mo  l > 

<Soec  stmt> 

< suo? 

spec> 

<save  stmt> 

< suo2 

sp*c> 

<other  soec  stmt> 

< sub2 

soec> 

<soec  stmt> 

<sub<? 

spec> 

<p arm  s t mt  > 

6b 


<sub?  spec>  <format  stmt> 


<sub3  func>  : 


<sub4  exec>  : 


<sub5  return> 


— 


<sub?  spec>  <entry  stmt> 

<subl  i mo  1 > <sf"t  func  stmt> 
< s up  1 imol>  <Oata  stmt> 

<sub2  spec>  <stmtfunc  stn,t> 
<sud2  spec>  <data  stmt> 
<blok3  data*  <entry  stmt> 
<main3  func*  <eni:  py  stmt> 

< s u o 3 f u n c > <stmtfunc  s t m t > 

< s u o 3 * u n c > <data  s t m t > 

<sub3  f unc>  < format  stmt> 
<suo3  furc>  <ent ry  stmt> 

<subl  impl>  <px?c  sfmt> 
<suo2  5p<?c>  <e*ec  stmt> 

<sud5  f unc>  <e*ec  stmt> 
<main4  e«ec>  <entrv  stmt> 

< 3ud 4 exec>  <e*ec  st">t> 

<sub4  exec>  <aata  stmt> 

<sub4  exec>  <tornnat  stmt> 
<sub4  exec>  <entpy  stnt> 

: = <return  stmt  > 


<b 1 ok  1 

i mp  1 > 

<return 

s t m t > 

<b 1 

spec  > 

< r e t u rn 

stut  > 

<b 1 ok  3 

dat  a> 

< r e t u rn 

s t mt  > 

< m a i n 1 

i mp  1 > 

<pet urn 

Stmt  > 

<ma i n<? 

soec> 

< r e t u r n 

S t mt  > 

<ma  i n 3 

f unc  > 

<ret  urn 

Stmt  > 

bb 


<main4  exec>  <retum  stmt> 


! <suOl  i mo  I > <return  stmt> 

! <suo?  spec>  <return  stmt> 

! <sut>3  func>  <return  stmt> 

! <suftU  exec>  <return  s t m t > 

! <suo5  return>  <return  stmt> 
! <sub5  return>  <exec  s t m t > 

! <sut>5  retupn>  <oata  stmt> 

! <sud5  return>  < f o rma  t s t m t > 
! <sud'5  ref  urn>  <ent  ry  stmt  > 
<soec  stmt>  ::=  <dimen  stmt> 


J < c 0 m o n stmt> 

! <enuiw  stmt> 

I <tyoe  stmt> 

<other  spec  stmt>  = <extepnal  stmt> 

! <intrinsic  Stmt  > 


<exec  s t m t > 


<ass  i qn  stmt> 

! <goto  stmt> 

! <apithif  s t mt  > 

J < I ogi f stmt  > 

! <do  stmt> 

J <cont i nue  stmt> 
! <ston  s t m t > 

J <pause  s t m t > 

! <pead  stmt> 

! <*Pite  stmt> 

! <p  p i n t stmt > 


J 
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